Week2 的攻擊手法，這篇開始逐一補防線

Week2 從紅隊視角演練了間接注入、Tool Abuse、Memory Poisoning、跨 Agent 連鎖攻擊。這篇開始 Week3 的藍隊防禦，先處理兩個互補的邊界控制：VPC Service Controls 管「資料能不能跨出邊界」，IAM Conditions 管「即使有權限，這次呼叫的情境對不對」。

VPC Service Controls 在 Agent 場景的應用

主題一 Day13 已經詳細談過 VPC-SC 的核心概念，這篇聚焦 Agent 場景的具體應用：當多個 Agent 分別部署在不同專案，或是 Agent 需要存取的資料橫跨多個服務（Vertex AI、Cloud Storage、BigQuery）時，把這些資源圈進同一個服務邊界，能直接防住 Day11 提到的「跨 Agent 連鎖攻擊」——就算攻擊者透過某個 Agent 取得了合法憑證，只要邊界設定正確，這組憑證依然無法把資料搬出邊界之外。

IAM Conditions：限制「這次呼叫的情境」

IAM Conditions 讓你在標準的 IAM 權限綁定上，額外加上情境判斷條件——例如限制某個角色只在特定時間範圍、特定資源前綴、或特定請求屬性下才生效。對 Agent 場景，這解決的正是 Day8 提到的 Tool Abuse 問題：即使 Agent 技術上有權限呼叫某個工具，也可以用 Conditions 限制「只有在滿足特定情境（例如任務類型標記為已核准）時，這個權限才實際生效」。

# 概念示意：限制某個角色只能在特定資源前綴下生效
bindings:
  - role: roles/aiplatform.user
    members:
      - serviceAccount:agent-sa@project.iam.gserviceaccount.com
    condition:
      title: "僅限已核准任務類型"
      expression: >
        resource.name.startsWith("projects/PROJECT/locations/asia-east1/approved-tasks/")

待實測提醒：IAM Conditions 支援的屬性與運算式語法（CEL, Common Expression Language）有其限制，並非所有情境判斷都能單靠 Conditions 達成，複雜的業務邏輯判斷仍需要在應用層額外處理。發布前請對照 IAM Conditions 官方文件 確認目前支援的屬性範圍。

兩者合起來防住什麼

VPC-SC 防「資料跨邊界」，IAM Conditions 防「不對情境的呼叫」——兩者疊加，能同時防住 Day11 的跨 Agent 連鎖攻擊（邊界圈住資料）與 Day8 的 Tool Abuse（情境限制呼叫），是這週藍隊防線裡最基礎的兩塊。

這篇的檢查清單

• [ ] Agent 涉及的多個專案是否已評估圈入同一個 VPC Service Controls 邊界？
• [ ] 高風險工具呼叫是否已用 IAM Conditions 加上情境限制？

💡 關於作者
我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。